System and method for transmission of information between locations on a computer network with the use of unique packets

ABSTRACT

System and method for transmission of information between locations on a computer network with the use of unique packets. A method is disclosed for communicating between first and second unlike systems. Information is generated at the first system in a first information format that is native to the first system. A first conversion system, in a first conversion operation, converts the generated information to a master space format such that a first converted information transmission is generated. The first converted information is then transmitted to a master information system. In response to receiving the first converted information at the master information system, the received first converted information is routed to a second conversion system in the master system format. At the second conversion system, the information transmitted thereto is converted from the master space format to a second information format in a second conversion operation to provide a second converted information transmission, the second information format being native to the second system. The second converted information transmission is then routed to the second system

This application is a continuation of pending application U.S. Ser. No.09/841,135, filed on Apr. 24, 2001, entitled SYSTEM AND METHOD FORTRANSMISSION OF INFORMATION BETWEEN LOCATIONS ON A COMPUTER NETWORK WITHTHE USE OF UNIQUE PACKETS.

TECHNICAL FIELD OF THE INVENTION

This invention is related to data processing systems and theirarchitecture. In one aspect, it relates to a network component forretransmitting data packets in accordance with ID codes embedded thereinin a distributed manner.

BACKGROUND OF THE INVENTION

The classification and management of data is one of the most difficulttasks faced by corporations, government entities, and other large usersof information. Companies must classify their data in such a way to makeit easy and simple for buyers to find and purchase their products. Dataexchanges face a bigger challenge in that they must work with multiplecompanies and develop a comprehensive classification system for theirbuyers.

One common way to create a search/classification system for specificproducts is to access and use government and/or industry specificclassification systems (i.e., classification databases). However, noexisting classification database is comprehensive enough to address allthe issues associated with building a classification system. Theseissues include: uniform numbers for products that cross multipleindustries, restricting products from inclusion in classification, andnon-usage of slang or industry standard language to access or classifyproducts. The classification databases frequently do not address all theproducts, thus resulting in inconsistencies even when companies use thesame classification system.

Additionally, many of the various classification systems conflict witheach other. For example, a product might have several classificationnumbers if it crosses multiple industries. Still other companies mightuse third party classification systems approved by a governmentalentity. This program requires companies to pay multiple fees and gothrough a lengthy administrative process. Even then it may not cover allproducts in an industry. Companies must make a conscious decision toinitiate, implement and maintain these programs. These efforts can becostly, and for this reason, compliance is generally not high.

A need therefore, exists, for a data processing system whichautomatically generates identification codes for specific products.Preferably, companies could use the automatically-generatedidentification codes in place of their existing identification codes.More preferably, the use of the automatically-generated identificationcodes can be phased-in gradually as the of user base expands.

Under current practices, companies create search engines by developinghierarchies and families of products. They may create a thesaurus toencompass slang words. Companies often use drop down menus, key wordsand product description capabilities to enhance their systems. It isdesired to classify the data in such a way as to minimize the responsesgenerated by a search, and therefore more effectively guide the buyerthrough the system. However, under current practices, most exchangesoffer barely adequate search capabilities for their buyers. Buyers mustclick through numerous drop down menus and then sort through multipleentries to accomplish their objectives. In many instances the buyer willfail to find the product that they seek. These existing processes couldtherefore be characterized as cumbersome, time consuming, frustratingand ineffective. A need therefore exists, for a product classificationsystem which can facilitate simple, rapid and effective searching byprospective buyers.

Another challenging data management task is the transmission of databetween dissimilar systems. Even within the-same corporate organizationit is very common to find different system types, applications and/orinformation structures being used. Transmitting data between suchsystems can be a time-consuming and expensive task. Under currentpractices, data transfer between dissimilar systems is often facilitatedby the use of customized software applications known as “adapters”. Someadapters “pull” data, i.e., extract it from the source system in thedata format of the host system or host application, convert the datainto another data format (e.g., EDI) and then sometimes convert it againinto yet another data format (e.g., XML) for transmission to thedestination system. Other adapters “push” data, i. e., convert the datafrom the transmission data format (e.g., XML) to an intermediate dataformat (e.g., EDI) if necessary, then convert it to the data format ofthe host system or application at the destination system, and finallyloading the data into the destination system. All of these adapter stepsare performed on the host systems using the host systems' CPU. Thus, inadapter-based systems, CPU load considerations may affect when and howoften data pulls can be scheduled. For example, data pulls may bescheduled for late nights so as slow down the CPU during daytime ONTP(on line transaction processing). A need therefore exists for a systemarchitecture which can allow the transmission of data between dissimilarsystems while minimizing the associated load imposed on the host systemCPU.

Network routers are known which direct data packages on a network inaccordance with ID codes embedded in the data packets. However, theserouters typically direct data packets between similar nodes on a singlenetwork. It is now becoming increasingly common to transmit data acrossmultiple networks, and even across different types of networks. A needtherefore exists for a router which can direct data over networks ofdifferent types in accordance with associated ID codes. A need furtherexists for a router which can automatically transform a data packethaving a first data format into a second data format.

It is well known that when large amounts of data are being transmittedbetween systems, a system error (i.e., stoppage) and/or data loss (i.e.,dropout) may occur. With conventional adapter-based systemarchitectures, debugging a system stoppage can be very challengingbecause of the large number of conversion processes involved, andbecause most systems do not have an integrated way to indicate the pointat which processing stopped, relying instead upon error logs. A needtherefore exists for a system architecture in which processing statusinformation is an integral part of the data packets transmitted over thenetworks.

Further, with adapter-based systems, even after the processes have beendebugged, it is often necessary to wait (e.g., until the time of daywhen host system CPU demand is low) to replace lost data in order toavoid adverse impact on the-company's business. For example, if the hostsystem is used for OLTP (on line transaction processing) during the day,pulling bulk data from the host system in order to replace data lost ina previous data transfer may be delayed until the late night hours. Ofcourse, the delay in processing the data can have an adverse impact ofits own. A need therefore exists for a system architecture which allowsfor the replacement of lost data while minimizing the impact on thesource host system.

SUMMARY OF THE INVENTION

The present invention disclosed and claimed herein, in one aspectthereof, comprises a method for communicating between first and secondunlike systems. Information is generated at the first system in a firstinformation format that is native to the first system. A firstconversion system, in a first conversion operation, converts thegenerated information to a master space format such that a firstconverted information transmission is generated. The first convertedinformation is then transmitted to a master information system. Inresponse to receiving the first converted information at the masterinformation system, the received first converted information is routedto a second conversion system in the master system format. At the secondconversion system, the information transmitted thereto is converted fromthe master space format to a second information format in a secondconversion operation to provide a second converted informationtransmission, the second information format being native to the secondsystem. The second converted information transmission is then routed tothe second system.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptiontaken in conjunction with the accompanying Drawings in which:

FIG. 1 illustrates an overall diagrammatic view of the system of thepresent disclosure;

FIG. 2 illustrates the detail of flow between elements of the system ofthe present disclosure;

FIG. 3 illustrates the flow of packets between elements in the systemand the conversion as the packets flow through the system;

FIGS. 4A-4D disclose diagrammatic views of the proprietary portion of atransaction packet;

FIG. 5 illustrates a diagrammatic view of databases at the host/clientand the conversion thereof to a proprietary routing ID packet;

FIG. 6 illustrates a diagrammatic view of one instantiation of thesystem of the present disclosure illustrating a transaction from a firsthost to a second host or client on the system;

FIGS. 7A and 7B illustrate two separate channels on the system;

FIG. 8 illustrates a flow chart depicting the initial operation ofgenerating the blocks of data for a transaction and scheduling thoseblocks for transmission;

FIG. 9 illustrates a flow chart depicting the data flow analysisoperation;

FIG. 10 illustrates a diagrammatic view of a transaction table that isformed during the transaction for analysis process;

FIG. 11 illustrates a flow chart depicting the export operation whereinthe data is polled and transmitted in packets;

FIG. 12 illustrates the operation of assembling the data packets;

FIG. 13 illustrates a diagrammatic view of a single channel and theprocesses performed in that channel;

FIG. 14 illustrates a diagrammatic view of two adjacent channels thatare utilized in completing a transaction or a process between an originand a destination.

FIG. 14A illustrates the joiner IDs for the two channels;

FIG. 15 illustrates a schematic diagram of three separate processsystems joined by separate channels;

FIG. 16 illustrates a diagrammatic view of the manner in which feeds arepropagated along a process chain;

FIG. 17 illustrates the process flow for the feeds in a given process ortransaction;

FIG. 18 illustrates a flow chart for the operation at each process nodefor determining from the feed the process to run and then selecting thenext feed;

FIG. 19 illustrates a diagrammatic view of three adjacent channels in asingle process flow;

FIG. 20 illustrates a diagrammatic view for a non-system host or originprocess node accessing a system process node;

FIG. 21 illustrates the process at the router for handling an out ofsystem process node that originates a transaction;

FIG. 22 illustrates a diagrammatic view of a simplified network forservicing a non-system node with the processes illustrated;

FIG. 23 illustrates an alternative embodiment of the embodiment of FIG.22;

FIG. 24 illustrates a more detailed diagram of the data packet;

FIG. 25 illustrates a detail of the preamble of the data packet;

FIGS. 26 and 27 illustrate the hierarchal structure of theclassification system associated with the data packet;

FIG. 28 illustrates a diagrammatic flow of a classification operation;

FIG. 29 illustrates a flow chart for creating a data packet;

FIG. 30 illustrates a diagrammatic view for associating an input profilewith a previous data packet, creating a new data packet;

FIG. 31 illustrates a block diagram for layering of data packets;

FIGS. 32 and 33 illustrate block diagrams for two embodiments of acommunication system for conversing between two nodes with data packets;and

FIGS. 34 and 34 a illustrate an example of communication with a datapacket.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to FIG. 1, there is illustrated a system diagram for thepresently disclosed system. There are illustrated three transactionalsystems, 102, 104 and 106. Transaction system 102 is comprised of arouter 108 that is interfaced with a network mesh 110, which networkmesh 110 is local to the system 102. The network mesh 110 allows therouter 108 to interface with various system nodes. There is provided ahost system node 114 that is the node at which a transaction arises.Also attached to the network mesh 110 is an archival server 116 and aconversion server 118, the function of which will be describedhereinbelow. Since the host system 114, the servers 116 and 118, and therouter 108 are all in the same network mesh 110, they communicate in acommon protocol to that of the network mesh 110, and also may have theability to communicate over the network mesh 110 with other networkprotocols that presently exist and any future protocols that would bedeveloped at a later time. This allows data packets to be transferredbetween the various nodes on the network mesh 110.

The router 108 is also provided with various media interfaces 120 and122. Media interface 120 allows the router 108 to interface with aprivate network 124 which could be any type of private network such as alocal area network (LAN) or a wide area network (WAN). This privatenetwork 124 can have other systems attached thereto such that the router108 can forward data through this network 124. The media interface 122is interfaced with a global public network (GPN) 126, which is typicallyreferred to as the “Internet.” This allows the router 108 to interfacewith the GPN 126 and the multitude of resources associated therewith, asare well known in the art.

The system 106 is similar to the system 102 in that it has associatedtherewith a central router 128. The router 128 is interfaced with anetwork mesh 130, which network mesh 130 is also interfaced with auniversal ID server 132 and a universal web server 134. The router 128is also interfaced with the GPN 126 with a media interface 136. As such,the router 108 could effectively interface with the router 128 and thenetwork resources in the form of the universal ID server 132 and theuniversal web server 134, the operation of which will be describedhereinbelow.

The third system, the system 104, is comprised also of a central router136, similar to the routers 108 and 128. The router 136 is interfaced onthe local side thereof to a local network mesh 138. Local network mesh138 has associated therewith three host or transaction nodes, atransaction node 140 associated with a system A, a transaction node 142associated with a system B and a transaction node 144 associated with asystem C, the transaction nodes 140-144 all interfacing with the networkmesh 138. In addition, the system 104 has associated with its localnetwork mesh 138 a core ID server 146, an account ID server 148, aconversion server 150 and an archival server 152.

Router 136 is operable to interface with the private network 124 via amedia interface 154, interfaced with the GPN 126 via a media interface156 and also to a transmission medium 158 through a media interface 160.The transmission medium 158 is an application specific medium thatallows information to be transmitted to an end user output device 162through a media interface device 164 or to be received therefrom. Aswill be described hereinbelow, this end user output device might be afax machine, and the transmission medium 158 a telephone system or thesuch that allows data in the form of facsimile information to betransmitted from the router 136 through the transmission medium 158 tothe end user output device 162 for handling thereof. The transmissionmedium 158 may be merely a public telephone network (PTN) that allowsthe number of the end user output device 162 to be dialed, i.e.,addressed, over the network or transmission medium 158, the callanswered, a hand shake negotiated, and then the information transferredthereto in accordance with the transaction that originated in the accessto the transmission medium 158. The transmission medium could include asatellite transmission system, a paging transmission system, or any typeof other medium that interfaces between one of the routers and adestination/source device. This will be described in more detailhereinbelow.

In addition to allowing the router 136 to directly interface with an enduser device 162 via the interface 160, there is also provided a fifthtransaction node 166 that is disposed on the GPN 126 and has accessthereto via a media interface 168. The transaction node 166 is operableto interface with any of the routers 108, 128 or 136.

In operation, as will be described in more detail hereinbelow, each ofthe transaction nodes 114, 140, 142, 144, is able, through the use ofthe disclosed system, to complete a transaction on the system andutilize the system to send information to or retrieve information fromanother transaction node on the system. In the private network 124,there is illustrated a phantom line connection between the router 108and the router 136. In order to facilitate a connection between, forexample, transaction node 140 for system A and, for example, transactionnode 114 for system D, it is necessary to create a unique data packet ofID's that can be transmitted via the router 136 through the network 124and to, transaction node 114 for system D. This unique proprietarytransaction packet that is transmitted utilizes various distributedresources in order to allow this transaction packet to be processedwithin the system and transmitted over a defined route that is definedin an initial transaction profile that is stored in the system atvarious places in a distributed manner. This will be described in moredetail hereinbelow. Additionally, the router 136 could also allow one ofthe transaction nodes 140-144 to interface with the router 108 throughthe GPN 126 such that a transaction can be completed with thetransaction node 114 for system D. This would also be the case withrespect to interfacing with the universal ID server 132 or the universalweb server 134, the transaction node 166 for system E or with the enduser output device 162.

Each of the routers 108-128 and 136 have associated therewith a datacache 170, 172 and 180, respectively. Whenever a particular router inone of the systems 102-106 has data routed thereto, data may be cached,then processed either outside the system or internal to the system, orthe data is maintained in the cache for later transmittal. The generaloperation of a transaction would require one of the transaction nodes todetermine what type of transaction was being made and the destination ofthat transaction. If it were determined that the transaction would bebetween transaction node 140 and transaction node 114 on system 102, aunique transaction packet would be generated that would have uniquetransaction IDs associated therewith that defined the routing path inthe system and the transaction associated therewith while processingwhat needed to be done between the two transaction nodes. As will bedescribed hereinbelow, this transaction is distributed over the entiresystem, with only a portion thereof disposed at the transaction nodeitself. It is the unique transaction codes or IDs that are embedded inthe information that is sent to the system that allows the transactionto be carried out in a distributed manner at all of the various elementsalong the path of the transaction.

As a further example, consider that transaction node 114 for system Dutilizes a different database than transaction node 140, i. e., the twonodes are in general incompatible and require some type of conversion orcalculation to interface data and transactional information. With thetransaction determined at the transaction node originating thetransaction, and a unique transaction packet created with the uniquetransaction information contained therein, all the necessary informationto complete the transaction and the routing of data follows thetransaction packet through the system. This, in association withinformation disposed in other elements or nodes of the system, allowsthe transaction to be completed in a distributed manner. In particular,the transaction packet is transmitted to various nodes which performthose discrete functions associated with the transaction packet for thepurpose of converting, routing, etc. to ensure that the transactionpacket arrives at the correct destination and achieves the correcttransaction.

Referring now to FIG. 2, there is illustrated a diagrammatic view of thesystem 104 and a transaction between transaction nodes on the networkmesh 138, which network mesh 138 is illustrated as a general network. Itis noted that network mesh 138 could be any type of network, such as anEthernet, a satellite, a Wide Area Network or a Local Area Network. Thetransaction is illustrated as occurring between transaction node 140 forsystem A and transaction node 142 for system B. Although the details ofa transaction will be described in more detail hereinbelow, thistransaction is illustrated in a fairly simple form for exemplarypurposes. The transaction is initiated at transaction node 140 togenerate information that will be transmitted to transaction node 142for system B. When the transaction is generated, the type of transactionis determined, the manner in which the information is to be transmittedto transaction node 142 is determined and the route that it will take isdetermined, and all of the information is embedded in a transactionpacket. This is a predetermined transaction that is completed with theuse of IDs that are utilized by various systems on the network toappropriately route information and to possibly perform intermediateprocesses on the packet and the data associated therewith. Further,transaction node 140 has associated therewith information to allow thedata that needs to be transferred to be transferred in a predeterminedmanner in accordance with a known profile of how transaction node 142wants the transaction to be completed and in what form the data is to berun. For example, it may be that transaction node 140 desires to order aparticular product in a particular quantity from transaction node 142.The data associated with the transaction or transactions would beassembled, in accordance with a predetermined transaction profile asdetermined by the system beforehand and in accordance with a businessrelationship between the transacting parties, and forwarded to theappropriate location in the appropriate format to be received andprocessed by transaction node 142. These are transactions thattransaction node 140 typically receives and handles in their day-to-daybusiness. As such, all transaction node 142 desires to do is to receivethe transaction in a manner that is compatible with its operationalenvironment. By using various conversion algorithms, routing algorithmsand the such, the transaction can be effected between the two systems ina distributed manner.

Although not illustrated in FIG. 2, and as will be describedhereinbelow, there is an initial setup that defines a profile for atransaction and a profile for a transaction node in the system. Wheneverit is desirable for transaction node 140 for system A, for example, tocreate a business relationship with transaction node 142, this businessrelationship will be set up on the system as a transaction profile. Oncethe transaction node is set up, the various information that isnecessary for the two transaction nodes to converse will be set up onthe system and “propagated” over the system such that the transactionprofile is “distributed” about the system. This will be described inmore detail hereinbelow.

In the transaction illustrated, the first step is to create thetransaction packet and route it to the router 136. This is facilitatedover a path “A” through the network 138. The router 136 is then operableto examine the contents of the transaction packet and the IDs associatedtherewith with a look-up table (LUT) 202. In the LUT 202, the router 136determines that this transaction packet is associated with a particulartransaction and that the transaction requires that any information forthis type of transaction being received from transaction node 140 betransferred to the conversion server 150. The router 136 thenreassembles the packet and transfers this transaction packet over thenetwork 138 to the conversion server on a path “B” and also stores theinformation in its associated data cache. Router 136 has, as such,“handed off” the transaction to the conversion server 150 and thencreated a record in its local cache 180. (This could be stored in nonlocal cache also, such as at the archive server 152.) It is noted thatthe transaction packet may be converted at each node along the path,depending upon the transaction and the action to be taken at each node.

At the conversion server 150, the received packet from the path “B” isexamined to determine information associated therewith. The conversionserver 150 also has an LUT associated therewith, an LUT 204. Theconversion server 150 recognizes that the information came from therouter 136 and has a predetermined transaction associated therewithmerely from examining the IDs, processing them through the LUT 204 andthen determining what type of process is to be performed on the datapacket and the contents thereof and where to forward them to. Forexample, the operation of the conversion server could be as simple asconverting the data from an SML language to an XML language, it could beutilized to translate between languages, or any other type ofconversion. Primarily, the contents of the transaction packet andassociated data that was retrieved from the database associated withtransaction node 140, associated with the transaction therein, mayrequire conversion in order to be compatible with the destinationtransaction node 142. The conversion server 150 places the data in theappropriate format such that it will be recognized and handled by thetransaction node 142. The specific manner by which this conversion isachieved is that setup in the initial setup when the businessrelationship between the two transaction nodes 140 and 142 was defined.The reason that this particular conversion was performed is that theagreed upon transaction set these parameters in the system for thisportion of the transaction which is stored in the LUT 204 at theconversion server 150.

After the conversion server 150 has processed data in accordance withthe transaction IDs within the data packet, the transaction data packetis then reassembled with the destination address of the router 136 andtransferred back to the router 136 via a path “C,” which may also modifythe transaction packet to some extent, as will be described in moredetail hereinbelow. Router 136 recognizes this data packet as havingcome from the conversion server 150 and performs a look-up in the LUT202 to determine that this particular transaction, determined from thetransaction IDs associated therewith, requires data received fromconversion server 150 to be transferred to the transaction node 142. Thedata is then assembled in a transaction packet and transmitted totransaction node 142 along the path “D.” Additionally, the previouscached data in cache 180 is replaced by the new data that is forwardedto transaction node 142. In some instances, it is desirable to archivethe data associated with this transaction. This is facilitated by thearchive server 152, wherein the data transmitted to the transaction node142 along the path “D” is also transferred to the archive server 152along a path “D′.”

As will be described hereinbelow, the entire transaction is determinedby a unique transaction packet that has embedded therein routinginformation in the form of ID packets, data, etc. The ID packets areunique numbers that are recognized by each of the nodes in the networkto which it is routed. By recognizing an ID packet, the particularrouter 136, conversion server 150, etc., has information associatedtherewith that allows it to perform the portion of the transactionassociated with that particular node, i.e., the conversion server 150performs a conversion and then routes it back to the router 136. In thismanner, the originating transaction node need not embed all thetransaction information therein and actually effect a direct connection,through a network or otherwise, to the destination transaction node inorder to complete the transaction, nor does the originating transactionnode require all the transaction information to be associated therewith.As such, the transaction itself is distributed throughout the network ina predetermined manner.

Referring now to FIG. 3, there is illustrated a diagrammatic view of themanner in which the packet is modified through the transaction. Anoriginating transaction packet 302 is generated at the originatingtransaction node 140. This is then transferred to the router 136,wherein the router 136 evaluates the transaction packet, determineswhere it is to be sent and then converts the packet to a “conversiontransaction packet” 304, which is basically the transaction packet thatis designated by the router 136 for transmittal to the conversion server150 via the path “C” with the necessary information in the form of IDpackets, data, etc., that will be required by the conversion server 150to perform its portion of the transaction, it being noted that thetransaction packet may undergo many conversions as it traverses throughthe system. The conversion server 150 then processes the data containedin the conversion transaction packet and then, after processing,converts it to a router transaction packet 306 for transmission back tothe router 136. The router 136 then converts this to a destinationtransaction packet 308 for transmission to the destination. It is notedthat the conversion server 150, after receiving the router transactionpacket, has no knowledge of where the destination of the transactionpacket will be eventually, as it has only a small portion of thetransaction associated therewith. All it is required to know is that thetransaction packet requires a certain action to be taken, i.e., theconversion process, and then this transaction packet must be transmittedback to the router 136. Since this transaction packet always hasassociated therewith the necessary ID information as to the transaction,each node that the transaction packet is transferred to or through willrecognize where the transaction packet came from, what to do with thetransaction packet and then where to transfer it to. Each node then willtransfer the transaction packet to the destination eventually in a“daisy chain” manner.

Referring now to FIGS. 4A-4D, there are illustrated diagrammatic viewsof the packet transmission which facilitates transmission of atransaction packet between transaction nodes or even nodes in a network.Prior to describing the formation of and transmission of the transactionpacket, the distinction must be made between a “data” packet and a“transaction” packet. In general, data is transmitted over a network ina packetized manner; that is, any block of data, be it large or small,is sent out in small “chunks” that define the packet. However, thepacket is a sequence of fields that represent such things as headers,footers, error correction codes, routing addresses and the data which issent as an intact “unit.” Sometimes, the data contained in the packet isactually a small portion of the actual overall data that is to betransmitted during a data transfer operation of some predetermined blockof data. These packets typically have finite length fields that areassociated therewith and some even have longer variable length fieldsfor the data. However, for large blocks of data, the data will bedivided up into smaller sub-blocks that can be sent in each packet.Therefore, for example, a large block of data would be sent to thenetwork controller for transmission over a compatible network to anetwork controller on a receiving device for assembly thereat. The blockof data, if it were large enough not to be compatible with a single datapacket, would be divided up into sub-blocks. Each of these sub-blocks isdisposed within a data packet and transmitted to the receiving devicewhich, once receiving it, will ensure that this data is then sequencedinto a combined block of data. If, for example, one of the data packetshad an error in it, this would be communicated back to the transmittingdevice and that particular data packet possibly retransmitted or theentire block of data retransmitted. Since each data packet has asequence number when sending a group of data packets that represent oneblock of data, the individual packets that each contain a sub-block ofdata can be reassembled to provide at the receiving device the entirepacket. This packetising of data is conventional.

With specific reference to FIG. 4A, there is illustrated the manner bywhich the data is actually transmitted. Typically, network controllersare arranged in multiple “layers” that extend from an application layerdown to a transport or network layer that inserts the data into a newformat that associates a data field 402 with a header 406. Theembodiment of FIG. 4A is referred to as an IPX data flow controller. Asnoted hereinabove, whenever a computer is attached to a network, itbecomes a node on a network and is referred to as a workstation. Wheninformation is sent between the nodes, it is packaged according to theprotocol rules set up in the network and associated with the networkcontroller. The rules are processes that must be complied with toutilize the operating system protocol layers—the application layer, thepresentation layer, the session layer, the transport layer, the networklayer, the data link and the physical layer—in order to actually outputa sequence of logical “1's” and “0's” for transmission on the networkmesh.

At the network layer, the data field 402, which was generated at theapplication layer, is associated with the header 406. This particularconfiguration is then sent down to the data link which is illustrated asa block 408 which basically associates the data field 402 with a UDPheader 410 and then translates this data field 402, UDP header 410 andthe IPX header 406 which is then translated into a new data field 412.This new data field 412 at the datalink is then associated with IPXheader 414 which is then again converted to a data field 414 associatedwith a media access controller (MAC) header 416 which is then compatiblewith the physical layer. The physical layer is the network mesh. Thisdata field 414 and header 416 are what is transferred to the network andwhat is received by the receiving device. The receiving device, uponreceiving the MAC header 416, recognizes an address as being associatedwith that particular receiving device and then extracts the data field414 therefrom, which is again utilized to extract the header 414 forexamination purposes and, if it is compatible with the device, then thedata field 412 is extracted and so on, until the data field 402 isextracted. Of course, data field 402 is only extracted if the datapacket comprised of the MAC header 416 and data field 414 is thatdirected to the particular receiving device. It is noted that alldevices on the network mesh will receive the data packet, i.e., they canall “see” the data packet traveling across the network mesh. However,the data will only be extracted by the addressed one of the devices onthe system. In this manner, a unique Universal Resource Locator (URL)can be defined for each device on the system. Typically, in an Ethernetenvironment, each network controller will have a unique serial numberassociated therewith, there never being two identical serial numbers inany network controller or network card for the Ethernet environment.

In the transaction packet, there are provided a plurality of smallerpackets that are referred to as “ID packets” that are generated in theapplication level. This basically comprises the data field 402. Thetransaction packet is formulated with a plurality of these ID packetsand data that are generated at the transaction node and modified atother nodes. This transaction packet, once formed, is transmitted to thenetwork level in such a manner that the appropriate header will beplaced thereon to send it to the appropriate location. Therefore, thesoftware or process running at the particular transmitting node on thenetwork will have some type of overhead associated therewith thatdefines the address of the source node on the network and also theaddress of the destination node. Therefore, when data is received by anyone of the nodes, it can recognize the defined field for the destinationaddress as being its address. Further, it can utilize the information inthe source address field, which is at a particular location in the datapacket, to determine where the data came from.

Referring specifically to FIG. 4B, there is illustrated a diagrammaticview of an ID packet 430. The ID packet 430, in the present disclosure,is comprised of a plurality of IDs, a core ID 432, a device ID 434 andan item ID 436. The core ID 432 is that associated with a particularentity on the network such as a corporation. For example, if acorporation had a profile set up, it would be assigned this particularcore ID when initiated. The device ID 434 is the unique ID of the deviceon the network. The core ID could be the corporation, and the device IDcould be the computer or program that is assigning item IDs. Forexample, if company ABC had an assigning device, a computer EFG, thecomputer EFG would be the creator of the ID packet. If device EFG wantedto assign a vendor ID to a particular vendor—the item, then vendor IDwould be set to HIJ. The value for the data packet would then beABC/EFG/HIJ. Note that the ID is actually not letters, but a combinationof codes and time stamps.

Each of the core ID 432, device ID 434 and item ID 436 are comprised oftwo blocks, a group block 438 and an individual block 440. The groupblock and the individual block 440 are comprised of a prefix 442, a timestamp 446 and a sequence number 448. The prefix is a sequence ofpredetermined prefixes that define various items associated with aparticular group or individual. For example, it could be that the setupof the profile define this individual as a vendor that had an accountwhich was a core ID and other various prefix values. As such, manydifferent companies or organizations could have the same prefix.However, once the prefix is defined, then the time that it is created isset in the time stamp 446 and then a sequence number is associatedtherewith in the field 448. Therefore, since only one entity will everassign the time stamp and sequence values, the entire block, 438 willcomprise a unique value or number or ID for that particular group. Forexample, if company A set up a profile, it would be assigned a uniquenumber that would always identify that particular company and this wouldnever change. As far as the individual block 440, this is a block thatfurther defines the core ID. For example, there may be five or sixdifferent divisions within a corporation such that this can be asubclassification. The notable aspect for this particular core ID 432 isthat it comprises a unique ID in the system and will define certainaspects of the overall ID packet 430, as well as the device ID 432,434and item ID 436. When all three of these core ID 432, device ID 434 anditem ID 436 are combined, this defines a unique ID packet 430 that isassociated with various information such as transactions, messages,pointers, etc. These are set up originally in the universal ID server132 in a profile origination step (not described) wherein a particularoperation can be associated with the ID packet 430. This wouldessentially constitute a relational database somewhere in the system.Therefore, as will be described in more detail hereinbelow, when this IDpacket 430 is assembled into the transaction packet, it is onlynecessary for any node to examine each of the ID packets and determineif any of the ID packets define operations to be performed by thatparticular ID packet. For example, if the ID packet represented atransaction such as a conversion, then the conversion server 150 in, forexample, system 104, would recognize the particular ID packet indicatinga conversion operation and also it might require information as to thedestination node which is typically information contained in an IDpacket, among other information, which defines exactly the process thatmust be carried out. For example, it may be that information is to beconverted from one language to another which is indicated by an IDpacket merely by the ID itself. With a combination of that ID packetindicating that transaction and the unique ID packet associated with thedestination, the conversion server could make a decision that aparticular process is to be carried out. This is facilitated since arelational database will be associated with the conversion server 150that will run a particular process therein. It is not necessary to sendany information to the conversion server 150 as to exactly what must becarried out; rather, only the particular ID is necessary which comprisesa “pointer” to a process within the conversion server 150. Once theconversion is complete, then the process that is running can utilizeanother ID packet contained therein for the purpose of determining whichdevice in the node is to receive the results of the process and exactlyhow those results should be packaged in a new transaction packet, itbeing noted that the transaction packet can be modified many times alongwith the transaction as it traverses through the system.

Referring now to FIG. 4C, there is illustrated a diagrammatic view of atransaction packet 460. The transaction packet in FIG. 4C is illustratedas being a plurality of “stacked” packets referred to as IDP1, IDP2,IDP3 and IDP4, followed by a data field 462, followed by additional IDpackets, IDP5 and IDP6 and so on. This transaction packet 460 can haveany length, it being noted that the length is due to the number of IDpackets, those being fixed length, and possibly variable length datafield 462. By examining the ID packets as they arrive, which occurs in asequential manner, then each of the ID packets can determine whatfollows and what action should be taken. For example, IDP4 may be an IDpacket that defines exactly the length of the field 462 and what data iscontained therein. Typically, these will be in finite length blocks.

Referring now to FIG. 4D, there is illustrated a more detailed exampleof a transaction packet 464. In this transaction packet, there areprovided a plurality of ID packets, IDP1, IDP2, IDP3-IDP6, and so on.IDP1 is associated with a transaction packet defining a predeterminedtransaction. As noted hereinabove, this is merely a pointer to a processthat is defined in code on the recipient node, if that node is actuallygoing to utilize the transaction. It is noted that this transactionpacket IDP1 may be a transaction that is designated for another node.Following the IDP1 data packet is provided the IDP2 data packet which isassociated with a message number. A message number comprises the real IDof a line of data in the database of the transmitting transaction node.Followed by this message number would be a block number in the IDP3 datapacket followed by a block of data in a data packet 466. The messagenumber and block number define the sequence of the data packet 466 forlater assembly. This could then be followed by the data packet IDP4 foranother message number and IDP5 for a block number followed by a datapacket 468 associated with the message number and block number of IDP4and IDP5, respectively. This is then followed by the IDP6 data packetfor another transaction. Therefore, various message numbers, blocknumbers, data, transactions, process IDs, etc. can be transmitted in IDpackets, it being noted that all that is sent is a unique value that, inand of itself, provides no information. It is only when there is sometype of relational database that contains pointers that can becross-referenced to the unique ID packets that allows the information inthe ID packet to be utilized. If it is a transaction, as describedhereinabove, then that transaction could be carried out by recognizingthe pointer to that process disposed at the node that is processing thedata.

Referring now to FIG. 5, there is illustrated a detail of a database atthe source transaction node H1. This is by way of example only. In thisexample, there are provided three separate tables that exist in thedatabase. These are tables that can be formed as a result of thetransaction or exist as a result of other transactions. It is noted thatthese particular tables are in the “native” database of the transactionnode. Typically, the databases will always be arranged in rows andcolumns with a row identification address (RID) associated with eachrow. With the row address, one can identify where the data is for thepurpose of extracting the data, updating the data, etc. When data isaccessed from the database or is processed by the database with thesystem of the present disclosure, information is associated with eachrow of data in two separate proprietary columns, which columns areproprietary to the system of the present disclosure. They are a column502 and a column 504. The column 502 is a date stamp on a given row,such that the particular row when accessed can be date stamped as to thetime of access. A row ID that is proprietary is also associated with theaccessed row. Therefore, whenever a row is accessed, it is date stampedand assigned a row ID. In this manner, even if the data is reorganizedthrough a database packing operation or the such, the data can still befound. As such, a unique identification number for a given row can begenerated with the proprietary row ID or the proprietary RID and thedate stamp, such that a large number of proprietary numbers can berealized.

When the databases are generated and put in the appropriate formats, itis desirable to transfer data that is stored for the purpose of atransaction to actually facilitate or execute the transaction. Thisutilizes a unique “Extent” for that transaction, which Extent is definedby an arrow 506 that converts the data in the appropriate manner to aproprietary transaction packet 508. The Extent 506, as will be describedhereinbelow, is operable to determine how to process data, extract itfrom the various tables, even creating intermediate tables, and thenassemble the correct ID packets with the appropriate data in atransaction packet and transfer this transaction packet to the network.Since the transaction is a profiled transaction for the whole network,the entire decision of how to route the data and ID packets to thedestination and the manner in which the data is handled or delivered tothe destination is not necessarily determined in the Extent at the H1transaction node. Rather, only the information necessary to “launch” thetransaction from the transaction node H1 is required and which IDpackets are to be included. Once it is launched to network, this uniquetransaction packet travels through the network and is processed inaccordance with the unique ID packets embedded in therein.

Referring now to FIG. 6, there is illustrated a diagrammatic view of twotransaction nodes 602, labeled H1, and 604, labeled H2, in a system thatare both associated with individual routers 606, labeled R1, and router608, labeled R2. Router 606(R1) is interfaced with the transaction node602 through a local network 610, which also has associated therewith twoconversion servers 612 and 616, labeled C1 and C2, respectively. Therouter 606(R1) is interfaced with router 608(R2) via a network 618.Router 608(R2) is interfaced with transaction node 604 through a localnetwork 620, network 620 also interfaced with a conversion server 622labeled C3.

In operation, there will be a channel defined for any given transaction.This channel will define the path that is necessary to traverse an orderto “hit” all the necessary processing nodes in order to effect thetransaction in the appropriate manner and in an appropriate format thatwill be compatible with transaction node 604 when it arrives thereat.Similarly, if the transaction node 604 desires to utilize the sametransaction back to node H1, it would merely use the same channel but inthe reverse direction. Similarly, another transaction could be definedfrom the transaction node 604 to 604 directed toward transaction node602, requiring an additional channel. Of course, each of these wouldalso require a unique feed ID packet that would define the varioussoftware that generated the various channels, ID packets and the datapackets, as described hereinabove.

Referring now to FIGS. 7A and 7B, are illustrated graphical depictionsof two channels. In FIG. 7A, there is illustrated a channel from H1 toH2 labeled “0011.” This channel requires the data to be generated at H1and transferred to R1. At R1, a conversion operation is determined to berequired and the data is merely sent to converter C1 (after possiblecaching at the router.) At conversion server C1, the conversion isperformed and then it is reassembled and passed back to R1. At R1, it isdetermined that the data packet has arrived from C1, and the next stepis to send it to converter C2. Converter C2 then performs theappropriate conversion operation, based upon the feed ID packet and theother unique ID packets in the transaction packet, and then transfersthe transaction packet back to R1. At R1, it is determined that thistransaction packet must be sent to another router, which is router R2.When sent to router R2, the routing information could be global or itcould be network specific, i. e., the channels might be specific only tothe systems associated with the appropriate router. In a situation likethis, an intermediate “joiner ID” is generated that defines a particularrelationship. This is an intermediate ID that is created for the purposeof this particular transaction. This joiner ID then is generated and theinformation sent to the router R2 which indicates that router R2 is totransmit the transaction packet to H2. It is known in this particularchannel and transaction that the transaction packet is alreadyappropriately conditioned for receipt by H2 and H2 will receive thetransaction packet, and know what type of transaction is to be performedat H2, i.e., it is aware of the unique ID packets and their meaning,such as the feed ID, packet how to process information once received,etc. It therefore understands the parameters within which thetransaction is to be effected.

In FIG. 7B, there is illustrated another channel, channel “0022” forperforming another transaction from H2 over to H1. This channel requiresthat the transaction packet be sent from H2 over to R2 and then from R2over to C3 for conversion. After conversion, the transaction packet issent from C3 over to R2 and then from R2 over to R1 with a joiner ID,similar to that of FIG. 7A. At R1, the data is transferred directly toH1. If the transaction for this particular channel is to be transmittedback to H2 along the same channel, the reverse path would be utilized.

Referring now to FIG. 8, there is illustrated a flow chart forinitiating a transaction. When the transaction is initiated, it isinitiated at a block 802 and then a transaction table is created. Thistransaction table will have data associated therewith with rows of datatherein in a predetermined format that is associated with the nativedatabase of the transaction node. This transaction table will then haveeach row therein stamped with a proprietary date and a proprietary RID,as indicated by the function block 804. Thereafter, the transaction flowwill be analyzed, in a function block 806, to determine how the data isto be arranged and transferred. This transaction is then scheduled fortransmission, in a function block 808. This is facilitated with aprocess wherein various calls are created for each block of data in thedatabase, as indicated by a function block 810 and then a run ID iscreated in a function block 812. After the schedule has been generatedand queued, the program then flows to an End block 814.

Referring now to FIG. 9, there is illustrated a flow chart depicting theoperation of analyzing the transaction flow in the block 806. The flowbegins at a function block 902 to extract select data from the databaseand assign destination information and source information thereto, i.e.,determine that the transaction comes from H1 and flows to H2. Duringthis extraction operation, the type of extraction is determined, asindicated by block 901. It may be a partial extraction or a fullextraction. The partial extraction is one in which less than all of thedata for a given transaction is extracted, whereas the full extractionextracts all the desired data in a single continuous operation. Theprogram in function block 902 operates in a filter mode and flows to adecision block 916 to determine if there is a restriction on the datawhich, if determined to be the case, will result in filtering bypredetermined parameters, indicated by function block 918. Thisrestriction operation is a filter operation that sets various parametersas to how the data is “pulled” or extracted. If not restricted, or,after restriction (filtering), the program will flow to a block 920 to afunction block 904 to then assign a transaction ID to the data.Optionally, there could be assigned thereto a joiner ID in the eventthat it was determined the data should go across to systems and thejoiner ID were appropriate. This joiner ID will be describedhereinbelow. The program then flows to a function block 906 wherein amessage number is assigned to each transaction. This message number isassociated with a row of data. The program then flows to a functionblock 908 to determine block flow. Typically, in databases, the data isextracted in one large block of records. For example, a giventransaction may require 10,000 records to be transferred over thenetwork. However, it may be that the recipient transaction node desiresonly 500 records at a time as a function of the manner in which theyconduct business. This, as noted hereinabove, is what is originallydefined in the profile for the business relationship or thetransactional relationship between the two transaction nodes. This,again, is predefined information.

After determining the block flow, the program flows to a decision block910 to determine if this is to be a divided block flow, i.e., the blockis to be split up into sub blocks. If so, the program flows to afunction block 912 to assign a block ID to each sub-block, such that theblocks can be assembled at a later time. The program then flows to adecision block 914. If it is not to be divided, the program will flowfrom the decision block 910 to the input of decision block 914.

Decision block 914 determines if more data is to be extracted from thelocal database of the transaction node initiating the transaction and,if so, the program flows back to the input of function block 902 to pullmore data. Once the data associated with the transaction has beenextracted, the program will flow to a block 920 to return the operation.

Referring now to FIG. 10, there is illustrated a diagrammatic view of asample transaction table. The transaction table is basically comprisedof the message number, the transaction ID, the joiner ID (if necessary),the row ID and date with proprietary identification system and the blockID. Also, a RUN ID can be assigned to each block as it is beingprocessed. The row ID in a column 1002 and the date in a column 1004 isdifferent from the database defining row ID in that they are alwaysassociated with the row. The row ID in the database is defined asfunction of the database and can actually change through variousrearranging of the database at the transaction node.

Referring now to FIG. 11, there is illustrated a flow chart depictingthe operation of actually exporting the data from the transaction table.This is initiated at a block 1100 and then flows to a function block1102 to pull the first block in accordance with the Extent that isrunning. It should be understood that all of the flow charts from thestart of the transaction to the end of a transaction are associated witha predetermined transaction Extent. This Extent, as will be describedhereinbelow, is a sequence of instructions or codes that are downloadedto the particular node to allow the node to conduct its portion of thetransaction in the predetermined manner defined by the transactionprofile that is distributed throughout the system. Not all of thenecessary transaction information is contained here but, rather, onlythe information or the process steps necessary to create and transmitthe transaction packet out of the system in the correct manner.

Once the data is pulled in accordance with the Extent running on thetransaction node, the program will flow from the function block 1102 toa decision block 1104 to determine if a caching operation is to beperformed. If not, the program will flow to a function block 1106 toprocess the block as pulled. If caching is required, the program willflow to a decision block 1108 to determine if the caching is done,before transmitting the blocks and, when complete, the program will flowto a decision block 1108, along with the output of the function block1106. The decision block 1108 determines whether an encryption operationis to be performed. If the data is to be encrypted prior to transmittingover the network, the program will flow to a function block 1110. Ifnot, both function block 1110 and decision block 1108 will flow to theinput of a function block 1112 to assemble the data packet. It is notedthat the encryption operation is something that is optional and doesrequire the overhead in each recipient node to decrypt the data. Thisfunction will not be described with respect to the remainder of the dataflow.

Once at the function block 1112, the transaction packet is assembled.The program then flows to function block 1114 to determine if thetransaction packet is completely assembled and, once complete, theprogram will flow to a transmit block 1116.

Referring now to FIG. 12, there is illustrated a flow chart for thetransaction packet assembly operation, as initiated at a block 1202. Theprogram flows to the function block 1204 to determine the size of thedata packet, whether it is a small group of ID packets in thetransaction packet or plural ID packets in the transaction packet. Oncethe size of the transaction packet has been determined, the programflows to a function block 1206 to determine the router to whichinformation is to be transmitted. It is noted that more than one routercould be on a network. The router is determined, of course, as afunction of the particular Extent that is running, this being the pathto which the packet will be routed. Once determined, the program willflow to a function block 1208 to insert the feed ID and the channel ID.It is noted that the feed ID and the channel ID are inherently a part ofthe Extent, this having been determined at the generation of the feedExtent which was generated during the profiling operation, as will bedescribed hereinbelow. The program then flows to function block 1210 toattach the Run ID thereto and then to a Return Block 1212.

Referring now to FIG. 13, there is illustrated a diagrammatic view of atransaction or process that is originated at an origin node 1302 fortransmission to the destination node 1304 on a single outgoing channel.As noted hereinabove, the outgoing channel defines the route and thetransaction. The origin node at 1302 utilizes a local Extent, indicatedby box 1306, to generate the transaction. In this transaction, there area number of IDs that are generated. One is a “RUN ID,” one is a “FEEDID,” and the third is a “CHAN ID.” Although there may also be other IDpackets that are generated, these three packets can basically define anentire transaction or process.

The origin node 1302, which can comprise the host node or the such,generates the transaction packet comprised of at least the RUN ID, theFEED ID and a CHANNEL ID and forwards it to a first process node 1306which processes the received transaction packet in accordance with theabove noted processes which then requires the transaction packet to bemodified and transferred to a second process node 1308 for furtherprocessing, which then forwards this to a third processing node 1310 andthen to a fourth processing node 1312 before final routing to thedestination node 1304. The destination node 1304, as describedhereinabove, can be the system router. Additionally, the router could beone of the processing nodes 1306-1312. This process will use a singleoutgoing channel for transferring a transaction packet from the originnode 1302 over to the destination node 1304. At the destination node1304, the information could be transferred out of the channel to anotherchannel, as will be described hereinbelow. Overall, this processingchannel is defined graphically as a block 1314. This graphicalrepresentation indicates that a transaction packet is generated and theprocess through various nodes in accordance with distributed processingdescribed hereinabove to route the transaction packet along variousprocessing nodes to the destination node 1304 for handling thereat.

Referring now to FIG. 14, there is illustrated a diagrammatic view oftwo channels adjacent to each other. In this embodiment, there isillustrated an origin node 1402 which is operable to generate atransaction packet, as described hereinabove, through two processingnodes 1404 and 1406 to a router 1408, labeled R1. This router R1 issubstantially the same as the destination node 1304 in the singleoutgoing channel noted with respect to FIG. 13. This combination of theorigin node 1402, the two processing nodes 1404 and 1406 and the router1408 comprise an outgoing channel. A second channel is associated with adestination node 1410. The overall transaction or process is operable togenerate the transaction at the origin node 1404 and route it finally tothe destination node 1410 for completion of the transaction. However,once the router 1408 has received the transaction packet, it then passesit over to a router 1412 labeled R2, which constitutes an incomingchannel for the destination node 1410. The router 1412 receives thepacket from router 1408 and passes it through two processing nodes 1414and 1416 to the destination node 1410. As noted hereinabove, the twosystems, the one associated with router 1408 and the one associated withrouter 1412 could handle the transaction packet and the ID packetsassociated therewith in a similar manner, i.e., that is, they couldutilize the same packet IDs. However, for security purposes, the originnode 1402 and the destination node 1410 utilize a different set of IDpackets referred to as joiner ID packets to transfer informationtherebetween. As such, within the outgoing channel associated withrouter 1408 and origin node 1402, there would be a defined set of systemassign IDs that would be proprietary to the origin node 1402. It may bethat the actual identification of these IDs is something that the originnode 1402 would not want to share with the destination node 1410.Therefore, the origin node 1402 and the destination node 1410 negotiatea relational database that associates an arbitrary joiner ID withvarious IDs at the origin node 1402 such that the IDs have no meaning inany system other than for the business relationship between the outgoingchannel and the incoming channel for the origin node 1402 anddestination node 1410, respectively. These joiner IDs are illustrated intables of FIG. 14A. You can see that router R1 has a table associatedtherewith wherein the joiner ID “0128” is associated with an ID packet“XXXX.” Whenever this joiner ID is received by router R2, a table forrouter R2 is examined to determine that this joiner ID “0128” isassociated with an ID packet “ZZZZ” therein. For example, it may be thatthere is a unique ID associated with origin node 1402 that defines it inan overall system. However, it may be that destination node 1410 definesthe origin node 1402 in a different manner, i.e., as “ZZZZ.” Rather thanredefine the joiner ID as “XXXX” in its system, it merely needs to havea joiner ID that defines the relationship between the two systems.Therefore, whenever the joiner ID “0128” is received as an ID packet,the router R2 will convert this joiner ID to the ID packet “ZZZZ” suchthat it now recognizes that ID packet as the vendor number of the originnode 1402 within its system. Other than within the system associatedwith destination node 1410, this has no meaning.

With respect to the joiner IDs, the joiner ID can be associated with thetransaction packet in any position along the processing path. Typically,the joiner ID is assigned at the origin node 1404 when running theExtent associated therewith, i.e., it is initially defined when the feedand the channel are assigned. However, it could actually be assigned atthe router 1408.

Referring now to FIG. 15 there are illustrated three separate processingblocks 1502, 1504 and 1506, similar to the processing block 1314. Eachof these processing blocks 1502, 1504 and 1506 represent a singlechannel and a processing system. For example, processing node 1502 couldrepresent a single company and its associated router, conversion server,ID server, archival server and host node. When performing a transactionto transfer to another system, the transaction packet is generatedwithin the processing node 1502, processed theretthrough in accordancewith the distributed processing system as described hereinabove and thenoutput from the processing block 1502 over to a second channel 1508 forrouting to the processing block 1504. The processing block 1504represents a third channel and an independent and self-containedprocessing block. For example, the processing node 1504 may be anintermediate processing node that allows independent processing of atransaction or processing event for transfer to the processing block1506. This could be, for example, a satellite system that constitutes anintermediate processing step. Once the transaction has been processedthrough the third channel, this is then transferred to a fourth channel1510 for transfer to the block 1506, which comprises a fifth channel.Each of these channels and each of these processing blocks compriseseparate distinct processing operations which all operate on the sametransaction packet (although the transaction packet may be modifiedsomewhat). Initially, the processing block 1502 originates at anoriginating node therein the transaction. This transaction has a channeland feed associated therewith, which channel comprised all of thechannels from the origin to the destination at processing block 1506.

Referring now to FIG. 16, there is illustrated a diagrammatic view ofhow the channel IDs and the feed IDs change as the transaction packet isprocessed through various processing nodes. As described hereinabove, achannel is defined as the route that a transaction path is to takethrough the various processing nodes. Since the processing isdistributed, the transaction packet must be routed to each node in orderthat the appropriate processing be carried out on that transactionpacket. Since the processing is predefined with respect to the channelID, very little information needs to be disposed within the transactionpacket in order to effect the processing. This transaction packet andthe packet IDs associated therewith in the form of the feed ID, thechannel ID, etc., define the portion of the processing that is to becarried out at each processing node, i.e., these constituting processpointers at each processing node. With respect to the channel ID, thisbasically remains the same in the transaction packet as the transactionpacket traverses a group of processing nodes. However, the feed ID willchange. The feed ID basically constitutes an instruction that isgenerated at one processing node for transfer to the second processingnode that defines the processes that are to be carried out. In general,this feed ID is a “tracer” that follows the process to flow from node tonode. As such, when one node receives a transaction ID from anotherprocessing node, it recognizes that the process is that associated withthe channel ID, but it also recognizes where in the process thetransaction packet is. For example, a router may handle a transactionpacket a number of times in order to effect transfer to one or moreconversion servers, effect transfer to an ID server, etc. With the useof the feed ID, the router now has knowledge of what process is to becarried out in the overall transaction process when it receives thetransaction packet from a given processing node. Additionally, anotheraspect that the feed ID provides is the tracing function wherein afailure at any point along the process path can now be tracked to theprevious process that was carried out.

With specific respect to FIG. 16, there are provided a plurality ofprocessing nodes 1602 labeled N1, N2, . . . , NK. Each of the processingnodes 1602, as described hereinabove, carry out a portion of the overalltransaction process which was predistributed to the processing node.Each of the processing nodes 1602 carries out a plurality of processes,labeled P1, P2 and P3 for exemplary purposes. It should be understoodthat any number of processes could exist at a particular processing node1602 that could be associated with a given channel ID or multiplechannel Ids for many other transactions apart from the currenttransaction. It is noted that each processing node can handle manydifferent processes and transactions. Once a transaction ID packet isconfigured, each processing node will receive that transaction packet,examine the transaction packet and determine exactly which process mustbe performed on that transaction packet, all of the effected with only afew ID packets of a fixed length.

When the transaction is initiated, it is initiated at the origin node,illustrated as a node 1604 for generation of a feed ID and a channel ID,labeled FEED1 and CHID1. This indicates at the origin node 1604 thatthis transaction packet is to be transferred to processing node N1. Whenprocessing node N1 receives the transaction packet, it recognizes thatthe process to be carried out is defined by the feed ID and it hasassociated therewith a FEED1 block 1606 that defines the process that isto be carried out. This block 1606 then can select between the availableprocesses P1-P3 for application to the transaction packet. Once atransaction packet has been processed in accordance with the selectedone of the processes (it may possibly require more than one process forthe processing), then the feed number is changed to the next feed ID,FEED2, and then the transaction packet is transferred with the samechannel ID, CHID1, to the next processing node, node N2. At this node,the processing node recognizes that this is the FEED2 feed ID andprocesses the data in accordance with a block 1608 for this particularfeed ID. Again, this selects between a plurality of processes foroperation on the transaction packet. Once processed, then the feed ID isincremented and the transaction packet transferred until it reaches thelast processing node in the processing chain, the processing node NK. Atthis node, this processing node will receive the feed ID, FEEDK, and thesame channel ID, CHID1. This will be processed with processing block1610 in accordance with the feed ID to select the process that is to beapplied to the transaction packet and then this is transferred out tothe destination.

It can be seen that this “hopping” operation allows the transactionpacket to be passed from one processing node to another. By incrementingthe feed ID along the processing chain, each processing node candetermine uniquely what process is to be carried out in the overallprocessing chain. However, it should also be understood that the feed IDprovides this tracer operation, but could be eliminated. It could bethat all that is required is the channel ID. Each processing node wouldreceive the channel ID and the processing associated therewith could beindicative of the process to be carried out by recognizing where thechannel ID came from. Therefore, an entire transaction could be carriedout with a single ID packet. For example, suppose that a transactioninvolved a conventional normal transaction between two business entitiesthat involve the transfer of 100 widgets to a particular warehouse. Oncethe business relationship is defined between two companies, then asingle channel ID could be transferred to the destination company which,upon receipt, would recognize that a particular transaction was to becarried out in a particular way for this particular vendor. It may bethat there are some conversions that are required during the process,which will require the ID packet to be transferred to a conversionserver to possibly assign a joiner ID to the channel Id in order toprovide some security to the system to prevent actual information at theorigin in the form of its unique vendor ID, etc., to be transferred tothe destination node. As such, it may be that some type of conversionoperation would be required to assign a joiner ID during the process inthe first company's system for transfer to the second company's system.It is noted that a company system is that defined by a router, a networkmesh, an ID server and a host node. Typically, the ID server, the hostnode, the conversion server, and the network mesh are all typicallyassociated and “owned” by a particular company.

Referring now to FIG. 17, there is illustrated a diagrammatic view ofhow the feed is incremented. This is initiated at a start block 1702 andthen proceeds to various feed blocks for the feeds FEED1, FEED2, . . . ,FEEDK. The process must go through each of the feed blocks and, at eachof the feed blocks, carry out the associated process. Therefore, thetransaction packet in effect not only carries a channel ID that can beutilized at a particular processing node to determine what transactionis being processed but also receive intermediate instructions toindicate what processes in the transaction are to be carried out. Asnoted hereinabove, it may be that the router is involved in the actualtransaction a number of times. Although a plurality of processes arepredetermined as being associated with the given transaction, theprocesses that are applied to the transaction packet are determined as afunction of where in the process the transaction is. The feed IDsindicate the position in the transaction for the purposes of determiningwhich predetermined transaction processes are to be applied to thetransaction packet when received at a particular processing node.Additionally, the feed IDs also provide for some failure analysis in theevent that a failure occurs. For example, in FIG. 15, one could examineany transaction or process from the origin to the final destination atany place in the process and determine where in the process it was.

Referring now to FIG. 18, there is illustrated a flow chart depictingthe operation of running the process at a given process node. Theprogram is initiated at a block 1802 and then proceeds to a functionblock 1804 to read the feed ID received in the transaction packet. Theprogram then flows to a function block at 1806 to run the process orprocesses associated with that feed ID and then to a decision block 1808to determine if all the processes have been run. If not, the programcontinues running processes in the block 1806 and, when complete, theprogram flows to a function block 1810 to increment to the next feednumber and then transmit the transaction packet to the next processingnode, as indicated by a return block 1812.

Referring now to FIG. 19, there is illustrated a diagrammatic view of aplurality of channels which indicate processing from an origin to adestination in each channel and then handing off to a second channel orsecond system. These are defined as channels CH1, CH2 and CH3. Inchannel CH1, there is provided an origin node 1902 and a destinationnode 1904 with two processing nodes 1906 associated therewith. In thesecond channel, CH2, there is provided an origin node 1908 and adestination node 1910 with three intermediate processing nodes 1912. Inthe third channel, CH3, there is provided an origin node 1914 and adestination node 1916 and three processing nodes 1918. The transactionis initiated at the origin node 1902 for final transmission to thedestination node 1916. However, between the destination nodes 1904 and1908, there is provided a line of demarcation 1920, with a similar lineof demarcation 1922 disposed between destination node D2 and origin node1914. The destination node 1904 could be a router and the origin node1908 could be a router in channel CH2. The line of demarcation 1920indicates that the first channel, CH1, basically “hands off” thetransaction to the second channel CH2 which processes the transaction inaccordance with a predetermined process set forth therein in adistributed manner across the various processing nodes for handing itoff to the third channel, CH3. Each of the line of demarcations 1920 and1922 define distinct boundaries such that the transaction packet can beconsidered independently handled for each of the channels. For example,it may be that in order to transfer from CH1 to CH2, a joiner ID isprovided. When handing off from destination 1910 to origin 1914 acrossline of demarcation 1922, a second joiner ID′ may be required.

Referring now to FIG. 20, there is illustrated a diagrammatic view ofone of the systems of 102-108 wherein a non-system node 2002 isinterfaced with the system 104 through a network 2006, which interfaceswith the router 136. The non-system node 2002, since it is not part ofthe overall system 104, is not identified in the system per se withoutsome processing in the system 104. In general, the non-system node 2002first must be identified and the transaction associated with its accessto the router 136 identified. Once this identification is made, then thenecessary transaction packet is assembled and the transaction conductedin accordance with the process described hereinabove. For example, thenon-system node 2002 will initiate a transaction merely by contactingthe router 136. This could merely be the transmission of a request to aspecified URL of the router 136 on the network 2006. The router 136,upon recognizing the URL of the non-system node 2002, i.e., the sourceURL, would recognize that a transaction is being initiated. The routerwould then create a transaction packet and route it to the conversionserver 150. The conversion server 150 would then convert informationreceived from the non-system node 2002 over to a format compatible witha transaction to be conducted with, for example, transaction node 140 onthe network mesh 138 in the system 104.

As an example of a transaction, consider that the non-system node 2002wanted to send an order via e-mail to transaction node 140. Tofacilitate this, non-system node 2002 would fill out a form in apredetermined order with information disposed in predetermined fields.This e-mail would then be routed to the router 136. The router 136 wouldrecognize the source of the e-mail and the fact that it was an e-mail.By recognizing both the source of the e-mail and the fact that it ise-mail, the router 136 would now recognize a transaction. It wouldcreate a form ID for the non-system node 2002, which would define thetype of form that is to be routed to the conversion server 150, andvarious other IDs that are associated with the transaction. This formand the form ID, in addition to other identification information in theform of ID packets, would be sent to the conversion server 150. Theconversion server 150 would then extract the information from the formin accordance with the form ID pointer, and convert this to informationassociated with the transaction. This would then be transferred totransaction node 140.

Referring now to FIG. 21, there is illustrated a flow chart depictingthe operation of the router 136 when receiving information from withinthe system and from outside of the system. The operation of the router136 is operable to receive data in the form of packetised data from thenon-system node 2002. This is indicated at decision block 2102. Theprogram then proceeds to decision block 2104 to determine whether thisis a system packet. If so, then this indicates that this is a systemnode and the program will proceed to a function block 2106 to processthe received transaction packet in a normal mode. If it is not a systempacket or transaction packet, the program would flow to a function block2108 to convert the packet to a system packet and then to the functionblock 2106.

Referring now to FIG. 22, there is illustrated a block diagram of asimplified embodiment of FIG. 20. In this embodiment, there isillustrated a situation wherein the non-system transaction node 2002 cando nothing more than access the router 136 and transfer informationthereto. As such, the router 136 must have some type of ID process,indicated by block 2202, by which to recognize the non-system node 2002and associate the transaction packet therewith, which involves the useof a form ID, as described hereinabove. Once the transaction packet iscreated by the router 136, then the transaction packet is routed to theconversion server 150 and a conversion process, as indicated by block2204, is run and the information received from the non-system node 2002converted to the appropriate format to complete the transaction.

Referring now to FIG. 23, there is illustrated an alternate embodimentof the embodiment of FIG. 22, wherein the non-system transaction node2002 has software associated therewith that allows it to form thetransaction packet. The non-system node 2002 has an ID process block2302 associated therewith that allows the non-system node 2002 to createa transaction packet. The non-system node 2002 has a definite ID on thesystem which has been defined in the original setup wherein the IDprocess in block 2302 was created and “pushed” out to the non-systemnode 2002. Whenever a transaction is to be implemented, the ID processis run and a transaction packet assembled. This transaction packet isthen forwarded to the router 136, in accordance with information in thetransaction packet. This is due to the fact that the transaction packetcreated by the ID process 2302 has a channel ID and the such containedtherein.

Once the router 136 receives the transaction packet, it recognizes thistransaction packet as one that exists on the system and routes it inaccordance with a routing process in a process block 2304. Thereafter,this transaction packet is modified, if necessary, and routed to theconversion server 150 for processing thereby. The routing to theconversion server 150 is in accordance with the channel definition setforth in the ID process 2302. Thereafter, the information is processedas described hereinabove with respect to FIG. 22.

ID Packet

Referring now to FIG. 24, there is illustrated a more detaileddiagrammatic view of the ID packet that constitutes the proprietaryportion of a transaction packet that is transferred over the network, itbeing noted that this ID packet is typically embedded within a datatransmission between the network with all of the commensurate overheadassociated with: such a transfer. As was described hereinabove, this IDpacket represents the smallest fixed length portion of a transactionpacket.

The ID packet is divided into three sections, a core ID section 2402, adevice ID section 2404 and an item ID section 2406. Each of the sections2402-2406 are divided into two sections, a “Group” ID and a “Individual”ID section. A detail is illustrated of the core section 2402. Each ofthe Group and Individual sections are comprised of three sections, apreamble section 2408, a time stamp section 2410 and a sequence section2412. As described hereinabove, the preamble section 2408 comprises aclassification section that is comprised of a plurality of“classifiers.” The time stamp section 2410 and the sequence section 2412provide a unique value that, when associated with a classifier section2408, provides a unique group value for the core section 2402. TheIndividual section is also organized as such. In the preamble section2408 of the Group section, it can be seen that there are a number ofclassifiers associated therewith. Of these, one classifier will alwaysbe the classifier “G.” There can be multiple other classifiers, it beingunderstood that the number of classifiers is finite. As will bedescribed hereinbelow, each of these classifiers is comprised of asingle alpha character, there being twenty-six alpha characters, each ofwhich can be represented by an ASCII value which is a finite lengthvalue. Of course, this limits the number of values to twenty-six foreach classifier field. There could be any type of value system utilized,it only being necessary that the field be a fixed length. For example,if the field were defined as a digital word having a four bit length,this would provide 2⁴ values. With respect to the preamble 2408 on theIndividual section, this also has a finite number of classifier fields,one of which will be the classifier “I” designating this as anIndividual ID.

The core ID 2402, device ID 2404 and item ID 2406 are illustrated inTable 1 as follows: TABLE 1 CORE (WHO) DEVICE (WHERE) ITEM (WHAT)Corporation or Assignee of the Packet, Object, e.g., article, net Entitye.g., computer, phone, etc. address, real estate property, etc.

The core ID 2402 is directed toward the basic owner of the ID packet.This, for example, could be a corporation, such as Corporation ABC. Thedevice ID is associated with the device that assigned the values in thepacket. For example, this could actually be the ID of the computer, thephone, etc. that actually was responsible for assigning the packet. Theitem ID is the subject of the data packet or the object, i.e., anarticle of commerce, a network address, a real estate property or thesuch. This is referred to as the “Who, Where, What” aspect of the IDpacket. For example, Corporation ABC is originally defined as the ownerof the ID packet. A unique core ID is initially associated with the ABCcorporation wherein a defined classification preamble 2408 is associatedtherewith and then a unique time stamp and sequence number. Thisclassifying preamble 2408 may actually be identical to theclassification associated with other corporations in the system.However, once the time stamp and sequence number are associated with thepreamble 2408, this core ID becomes unique as to that corporation orentity against others. When an object or item is being incorporated intoan ID packet, i.e., an ID packet is being created to uniquely definethat item in the system, there is some device on the system thatactually creates this ID packet. For example, it might be that acatheter is being uniquely defined in a company. There will be possiblya computer terminal on which the information is entered. This computerterminal has an ID in the system and it is this ID that comprises thedevice ID. Therefore, once the ID packet is created, the entity(corporation) then owns the ID packet. The object, i.e., the catheter,is classified and is also known which device assigned the ID packet orcreated the ID packet.

Referring now to FIG. 25, there is illustrated a more detailed diagramof the preamble 2408. The preamble 2408, as described hereinabove, iscomprised of a plurality of fields. These are referred to in FIG. 25 as“F1, F2, F3, F4, F5, . . . ” There are a fixed number of fields for thepreamble 2408 which, in the present disclosure, are fixed for each GroupID and Individual ID for each of the core, device and item IDs. However,it could be that the fields differ between preambles, the onlyrequirement being that they do not differ between ID packets. A typicalfive field preamble section of an ID is illustrated in Table 2 as itexists in the database, understanding that more fields may beincorporated. TABLE 2 F1 F2 F3 F4 F5 TS/SEQ CONTENT A B Z C W XXXX — C TQ I C XXXX — F L A K L XXXX — G M B R S XXXX —

With reference to Table 2, it is described hereinabove that each fieldhas an alpha character associated therewith. This alpha character has apredefined relationship for the classifier. For example, if a field wereassociated with the type of ID, there could be two values, oneassociated with a permanent ID and one associated with a joiner ID. Thiswould therefore be a field having only two values. It could be that thisutilized the alpha characters “P” and “J.” However, it could use anyalpha character (number, character, symbol, etc.), it being recognizedthat the value or relationship (meaning) of the characters isunimportant; rather, it is the relationship of that packet disposed inother locations in the system that is important. In TABLE 2, it can beseen that the database associated with a particular ID has associatedtherewith the fields in the preamble, the time stamp/sequence field(TS/SEQ) section in addition to a content column. The content columndefines what this preamble is associated with. For example, if this werethe Group ID in the core ID 2402, then this could refer to, for example,a content of “chemical corporations.” If this were Corporation ABC, thenthe Individual ID would have a preamble field that might be common withother individual corporations but the TS/SEQ section would be uniqueonly to that corporation and the content associated with that particularcorporation would have the term “Corporation ABC” in the content column.It may be that there are ten corporations that have identical preamblesbut different TS/SEQ values and, therefore, the core ID 2402 would beunique to that corporation. Each of the Group ID and Individual IDs forthe core, device and item IDs in the ID packet would be configuredsimilarly.

As will be described hereinbelow, although each of the fields in thepreamble 2408 is defined as having only 26 values due to the choice ofan alpha character as the classifier, one of the fields can be combinedwith the TS/SEQ value to provide a larger value associated therewith.Since the TS/SEQ value can comprise a unique and very large number, itdoes not constitute a classifier as such. By combining the twenty-sixalpha numeric values each with the TS/SEQ value, the number ofclassifiers for that particular field becomes very large. For example,if one wanted to define a field in the preamble for the item ID 2406 asthe field that defines the item, more than twenty-six item classifierscan now be provided. As a simple example, it could be that there are aplurality of catheter types in a company such as a pulmonary catheter, acardiac catheter, etc. If there are more than twenty-six of these typesof catheters, there would be required more than twenty-six classifiervalues. By combining an alpha character with the time stamp, the numberof available classifiers can be increased in value.

Referring now to FIG. 26, there is illustrated a diagrammatic view ofthe classification scheme. There are illustrated four fields that arebeing classified in a preamble, it being understood that more or lessfields could be defined for the preamble structure, with only threevalues illustrated for each field. However, each of these values can beconditional upon the previous path, as will be described hereinbelow. Inthe field F1, there are illustrated three classifier values, A, B, C.The classifier of interest in field F1 is “A.” There are illustratedthree paths from this classifier, since field F2 is only associated withthree classifiers, these being again, A, B, and C. It should beunderstood that the classifications being associated with the classifierA is not necessarily the same classifier associated with the classifierA in field F1. Also, the classifier B in field 1 may also point to threeseparate classifiers A, B and C in field F2. However, it should beunderstood that the classifier A in field F2 that the classifier B infield F1 could point to may not be the same as classifier A in field F2pointed to by the classifier A in field F1. The classifier in any one ofthe fields below field F1 has a value that may be conditioned upon theclassifier in the previous field from which it derives. It can be seenthat each of the classifiers in field F2 will point to one or moreclassifiers in the next field F3, there being illustrated three, A, Band C. Further, field F4 further expands this will three classifiers, A,B and C for each of the classifiers in field F3. Again, although thereare illustrated as multiple classifiers A in field F3, they are notidentical in value or classification function but, rather, they areunique to the associated path.

With reference to FIG. 27, there is illustrated a single path through agiven preamble of a field width of four. In the Group ID, for example,the preamble may be classified as “A” in field F1 and it may point toclassifier “B” in field F2. Although the path could go to classifiers“A” or “C” only one path is selected. At field F2, classifier B pointsto classifier “A” in field F3 and classifier “A” in field F3 points toclassifier “B” in field F4. Therefore, once it has been determined thatfield F1 has classifier A, then the next determination must be which ofthe classifiers in field F2 associated with classifier A in field F1will be selected. It is this association of classifiers in a lower fieldwith those in an upper field that defines the classification scheme.Again, it could be that classifier “B” in field F1 could point to aclassifier “B” in field F2 that is different than that associated withclassifier “A” in field F1. However, it could be that some fields haveidentical classifiers for each of the above fields. For example, in theGroup ID, the last field will always be “G” defining the Group ID assuch (not a conditional classifier.) The individual ID will always havea “I” in the last field thereof defining it as such. Therefore, thereneed not be any association between fields though there can be anassociation. With respect to the Individual ID, this follows the samepath as the Group ID with the exception that it is defined as havingvalues of“D,” “E,” and “F.”

The ID that is generated will be stored in a table in the database ofthe ID server with alpha titles that can be searched, in associationwith the code associated therewith. A typical table in the database isillustrated in Table 3. In Table 3, the field F1 is associated with anID that is either a permanent ID or joiner ID. This is referred to asP/J in one column, this is defined as a permanent or joiner field withthe code associated with the permanent field being a “P” and the codeassociated with the joiner field with the joiner value being a “J.” Thesecond field F2 is associated with different types of devices areIndividual IDs or Group IDs, defined, in this embodiment as a profiletype, a network type or a system type. Therefore, the one column willdefine the type as being profile, network or system and the codeassociated with the profile type will be “F,” the code associated with aprofile type would be “P,” with a network type would be “N” and with asystem type would be “S.” Field F3 is associated with an item whichcould be a type of computer such as an Apple computer, an item such as acatheter, a URL for a network address or the name of a system such asAVC or with a system referred to as a PPLL, this basically being anacronym for some type of system in the industry, as an arbitraryexample. In this example, the code is the combination of an alphacharacter plus the time stamp for that row, to provide a large number ofvalues therefor. In field F4, this is the category of the ID which, inthis example can either be a core ID or a vendor ID. If it is a core ID,it will have a code of “C” and if it is a vendor ID, it will have a codeof “V.” There will also be a time stamp associated with each row. It canbe seen that there are two IDs having identical values in all of thesefields with the exception that field F3 is associated with differentcatheters. As such, the code value would be distinguishable between thetwo because the code P+TS is associated with a different time stamp.This is what makes these two IDs distinct, even though they areassociated with the same item, they are both vendor IDs, they are bothpermanent IDs and they are both profile IDs. By utilizing the time stampin association with a alpha character, a much larger number of items canbe defined for this particular field.

Referring now to FIG. 28, there is illustrated a diagrammatic view ofthe method in which the data packet is created and the databasepopulated with the data packet. Initially, a profile screen 2802 isprovided which provides a plurality of user modifiable fields 2804 thatallow the user to insert information. Each of these fields is utilizedfor the classification operation. Sometimes, this is an interactivesystem wherein inserting information into one field will result inanother type of field being made available. For example, if somebodywere classifying a data packet as being associated with a network, itmight be that the URL of the network were provided as a possible inputfor another classifier, whereas that particular classifier, the URL,might not be appropriate for a previous classifier.

Once the user has inserted all of the necessary information, then theflow would move to a block 2806 wherein the information that is input bythe user would be classified into the preamble of the appropriate ID inthe data packet. This, as described hereinabove, would be required inorder to classify all of the IDs in the ID packet. For example, whenfilling the profile, a corporate name would be specified whichautomatically would pull up the core ID for that corporation. Of course,the device that is being utilized to fill in the profile would alreadybe known and would constitute the device ID. The remaining portion ofthe profile 2802 would be utilized for the purpose of providing the itemprofile. The classifier would assemble all of this information and thenflow to a block 2808 wherein the data packet is populated and thedatabase is populated, as indicated by block 2810. This population ofthe database would provide information associated with the ID packet, asset forth in Table 3, such that all of the information necessary toidentify a ID packet is contained therein. Table 3 is as follows: TABLE3 F1 F2 F3 F4 P/J Code TYPE Code ITEM Code CATEG Code F5 Perm P ProfileP Apple D + TS CORE C — Perm P Profile P Cath P + TS VN V — Perm PProfile P Cath P + TS VN V — Perm P Network N URL P + TS VN V — Perm PSystem S AVC A + TS VN V — Join J Profile P Cath Z + TS CORE C — Join JProfile P Cath F + TS CORE C — Join J Network N URL L + TS VN V — Join JSystem S PPLL N + TS VN V —

As such, the ID packet now provides a method to “point” to a specificrow in the database, due to the fact that all of the preambles and thetime stamps exist. Although Table 3 illustrated only a single ID in theID packet, it should be understood that each ID packet is represented byall of the IDs, which comprise a single row in the database. Thisdatabase is typically populated at the ID server and then the ID server,as described hereinabove, “pushes” all of the ID packets in the databaseto the respective account servers such as the conversion server, therouter, etc. Also as noted hereinabove, some of these ID packets couldidentify processes. In this situation, it might be that all of theinformation in the database and an ID server need not be transferred toeach and every one of the accounts such as the conversion server and therouter. Only the information associated with data packets that would beprocessed or handled by that particular server would be required at theconversion server, router, for example.

Referring now to FIG. 29 there is illustrated a flow chart depicting theoperation of entering a profile. The program is initiated at a block2902 and then proceeds to a block 2904 to enter the profile, thistypically performed by a user. It could be that, additionally, a profilethat is received in the form of a filled out “form” that is provided bysome input device from a non-system user. That is, for example, orderinga product from a system node in a transaction. If the profile alreadyexists, as determined by a decision block 2906, then the program willflow to a function block 2910 to use an existing ID. However, if the IDdoes not presently exist, the program will flow along a “N” path to afunction block 2912 wherein a time stamp will be applied and then tofunction block 2914 where a sequence number will be assigned. Typically,if this particular device is creating new packets, a different sequencenumber will be attached to the various time stamp in a predeterminedsequence. However, this could be a random sequence. The program thenflows to a function block 2916 to store the ID and then to a decisionblock 2918 to determine if more profiles are to be entered. This is alsothe destination of the function block 2910. If more are required, thedecision block 2918 will flow back to the input of function block 2904and, if not, the program will flow to an End Block 2920.

Referring now to FIG. 30, there is illustrated a diagrammatic view fordefining a single ID in an ID packet. This ID is associated with theprofile for a butterfly catheter. This typically will be the item ID.There are provided, for example, six fields, the first associated withwhether it is a permanent or a joiner ID, defined by a “P” or a “J.” asecond field associated with whether it is a profile, which is indicatedby “P,” an item type defining what type the item is, indicated by a wordas a user would input it, a fourth field associated with the actualitem, i.e., that it is a butterfly catheter (the lowest classification),a fifth field for the overall type of ID packet, this being an “ID”packet, indicated by an “I,” indicated by “C” or a “V,” respectively,and a sixth field associated with the type of ID it is, an IndividualID, “I” or a Group ID “G.”

In the first profile input, the user indicates it as being a permanentID, a profile and types out the word “catheter” for the item type, andtypes and the word “butterfly” of the item that it is associated with anID, “J,” and that it is an item ID indicated by an “I.” The term“catheter” is associated with an alpha letter “C” and the word butterflyis associated with the letter “B.” When this is first created, the IDthat is generated is “PPCBITS/S.” The second item that is entered isidentical to the first one in that the user indicated this as being abutterfly catheter. The system will recognize all of the first three andlast two classifiers as being identical to others in the system and itwill also recognize that the term “butterfly” as identical to a previousone that was entered. This type of search during the classificationoperation is performed by actually looking at the database in thenon-coded column for the particular word in the field. This essentiallylooks at the spelling of the word. Since the spelling is the same as aprevious one and the first three and last two fields are the same, thenthis will be identical to an ID packet that exists and a new ID packetneed not be created. However, suppose a situation occurred where theuser misspelled the term “butterfly” as “butterfly.” In this situation,the database search would not turn up this misspelling (this is assumedthat the system does not have some type of spell check to allowadaptability to this type of situation) which basically determines thisas a new item in the database. As such, a new alpha character will beassociated with the item field, i;e., the fourth field, which is thealpha character “L” associated with the time stamp and this willcomprise a new row in the database. For the last example, suppose thatthe item that is to be classified as a butterfly catheter with thecorrect spelling, but that the fifth field is a pulmonary description.In this event, this will be a different ID and may actually result in adifferent alpha character for the fourth field associated with the item.As illustrated, this can be assigned as an alpha character “P,” whichmay be different, but it uniquely identifies this as a different itemassociated with a pulmonary catheter. However, it is the time stamp thatmakes it unique even if the same character is used.

Referring now to FIG. 31, there is illustrated a diagram of a system forlayering data packets received from different systems that arepotentially “non-like” systems. There are illustrated three systems, asystem 3102, a system 3104 and a system 3106, labeled system “A,” “B”and “C,” respectively. Each of these systems operates in a differentenvironment and may actually have a different database structure. Forexample, one might utilize an Oracle database with a specific andclearly defined database structure and another system might utilize adifferent database structure. Each of these database structures is anindependent structure with possibly separate methods for identifyingvendors and the such, i.e., there can actually be a different vendornumber in each system for the same vendor or a different product numberfor a common product. However, in the overall system utilizing the IDpackets, there can only be one common ID for a packet associated withany vendor or item. For example, if a field were present for an employeenumber associated with an employee, a field present for the days workedand a field present for the days out of the office, each of theseparticular types of data would be reflected in a different format ineach database. Therefore, a specific employee number from one databasewould have to be converted into an ID packet format for the mastersystem such that both systems employee number could be recognized,categorized and analyzed, or transferred from one system to the other.

The manner for converting data and information in one database to themaster system is provided by the extensions referred to hereinabove as“Extents,” that provide a software program for retrieving informationfrom the non-master database and converting it to ID packets from themaster system. System 3102 has associated therewith an Extent 3108,system 3104 has an Extent 3110 associated therewith and system 3106 hasan Extent 3112 associated therewith. Each of the Extents 3108 isoperable to retrieve the data and forward it to a conversion server 3114as ID packets. The interface connection between the Extents 3108-3112and the conversion server 3114 are illustrated as separate connections,but they are actually transferred through the network. Additionally,there could be multiple inputs to the conversion server from differentnetworks.

Each of the Extents is interfaced to an ID server 3116, which ID server3116, which ID server 3116 is operable to “push” IDs for various itemsand the such to each of the associated Extents. For example, if system3102 had associated therewith database information that was to beconverted over to an ID packet out of the ID packets associatedtherewith would be stored in the Extent 3108. When initially set up,system 3102 would recognize for example, that each employee in itsdatabase required a separate ID packet to uniquely identify thatemployee. These would be set up by the ID server 3116 and pushed to theappropriate Extent 3108. Therefore, whenever system 3102 transferred anemployee number as part of a data transfer to the conversion server 3114or any other account server on the system, it would be processed throughthe Extent 3108 and the appropriate ID packet generated, i. e.,extracted from the associated ID packet table of the Extent 3108, andthen forwarded to the conversion server 3114. In the example of FIG. 31,the conversion server 3114 is illustrated as the destination of theinformation for the purpose of layering, as will be describedhereinbelow. However, it should be understood that all of the data willfirst go to a router and then to the appropriate account server, ifnecessary. The illustration of FIG. 31 is simplified for this example.

When data from system A is received for a particular conversionoperation, it is stored in a database 3118 in a first location 3120. Allthe data from system 3104 is associated with a location 3122 and all theinformation from system 3106 is associated with a location 3124 indatabase 3118. This information is layered, such that common ID packettypes, such as employee numbers, are arranged in a predetermined format.This is illustrated in a Table 3126, which is organized to illustratefour ID packets, IDP1, IDP2, IDP3 and IDP4. IDP1 may be employee numberswhich are arranged in three locations, such that they all are in acommon column. It should be understood that each of the IDPs can bedifferent for employee numbers, i.e., each employee has a separatedistinct ID packet. As such, if system 3102 and system 3106 both had thesame employee in their database, they would have a common ID packetassociated with the ID server 3116, this being set up initially. It canbe seen, therefore, that the layering system allows a transaction or ananalysis to pull data from non-like systems, convert it to like data inan organized structure and dispose it in a common table that will allowanalysis thereof. An example of this will be described hereinbelow.

Referring now to FIG. 32, there is illustrated a diagrammatic view ofthe transaction system for utilizing ID packets to converse between twosystems through a master space. As described hereinabove, this masterspace includes the router, the network mesh, the core servers, the IDserver, etc. that are required to process data packets. In FIG. 32, thissystem is illustrated with a block 3202 that defines the master datasystem. The master data system is essentially a system that receives,routes and operates on data packets to perform processes, etc. Asdescribed hereinabove, each of these ID packets constitutes a pointer tosome process associated with traversal of information through the masterdata system 3202 from an origination point outside the system to adestination point outside the system through the master data system 3202or to a point within the master data system for processing thereof. Thisprocessing system is referred to with a block 3204 which is operablethat is also provided a master ID server 3206 that contains the IDpackets that are operable with the system, these referred to as internalID packets. These are differentiated from external ID packets for anexternal system, which is not disclosed herein.

There is provided an external system 3208 that interfaces with themaster data system 3202 via a conversion block 3310, system 3308 havinga local database 3312 that is associated with its native databaselanguage or structure. Similarly, there is provided a second system 3314that is interfaced with the master data system through a conversionblock 3316 and has associated therewith a native database 3318. In orderfor system 3308 to interface with system 3314, it is necessary toextract data, convert it to an ID packet that is compatible with amaster data system 3202, process it therein and then route it to system3314 through the conversion block 3316, at which time it arrives atsystem 3314 in a structure similar to the native database 3318. Thisallows non-like systems to communicate with each other as long as theyhave a common space to go through.

In order to operate in this manner, there must be some type ofconversion to the master data space. This is not necessarily defined bythe system itself, but, rather, the master data system 3202 through itsID server 3206 defines the manner by which each system will communicatetherethrough. As such, this is a push operation with the definition. Notonly are the parameters of the definition assigned, but the actual IDpacket that is communicating therebetween. For example, there mayactually be a common item, such as a catheter, that exists in bothdatabases. By having this information determined by the master ID server3206, an ID packet can be generated in the master ID server 3206 andassociated with the same items in the two different databases 3312 and3218. As such, it is important that the master ID server be able toidentify the ID packet and associate it with the same item in twodifferent databases such that, when pushing the ID packet to one of thesystems, it also pushes the associated relationship to information inthe database 3312 or 3318. For example, an employee number in database3312 has a certain format and value that is set up in the master IDserver 3206 as being related to a specific ID packet. When the ID packetis transferred to the conversion block 3310, it is associated with itsvalue in the database 3312. Therefore, whenever the value in database3312 is sent to the conversion block 3310, this value acts as a pointerand the appropriate ID packet can then be forwarded to the master datasystem 3202.

Referring now to FIG. 33, there is illustrated an alternate embodimentof the embodiment of FIG. 32. In this system, there are provided twosystems, a system 3302 and a system 3304. System 3302 has associatedtherewith a master data system 3306 and a master ID server 3308. System3304 has associated therewith a master data system 3310 and a master IDserver 3312. There is provided one external system, system 3314associated with system 3302 in a conversion block 3316 disposed betweensystem 3314 and master data system 3306. There is associated in a localdatabase 3318 with system 3314. ID server 3308 is internal to the masterdata system 3306. Therefore, whenever system 3314, which is part ofsystem 3302, communicates with master data system 3306, it will useinternal ID packets associated with the ID server 3308, as describedhereinabove. However, when conversing with master data system 3310, theID packets are different, they are those associated with ID server 3312,these being external to system 3302. Therefore, master data system 3306has stored in ID server 3308 external ID packets associated with theexternal side of the system, i.e., all other systems that are externalthereto.

System 3304 has associated therewith an external system node 3320, whichcommunicates with master data system 3310 through a conversion block3322 and also has associated therewith a local database 3324.

When a transaction occurs which requires information to be transmittedfrom system 3314 over to system 3320, a data packet will be generatedfor information in the local database 3318. For example, if a simpletransaction such as an employee number was required to be transferred tosystem 3320 for operations thereon as a portion of a process, theemployee number would be extracted from D database 3318 with theconversion block 3316, as part of the overall transaction. This employeenumber would be converted to an internal ID packet associated withsystem 3302. At the master data system 3306, information in the IDserver 3308 would be utilized to determine the external data packet tobe transferred to master data system 3310. As described hereinabove, itcould actually be the ID packet associated with the employee number thatresides in ID server 3312. Alternatively, it could be a joiner ID packetwhich is a negotiated ID packet between the two systems, such that theactual ID packet associated with the employee number in either of thesystems 3302 or 3304 is not known to the other.

Once the ID packet, with a joiner ID packet, are transferred from masterdata system 3306 to master data system 3310, it is the processed inaccordance with the transaction and transferred to the conversion block3322 as the appropriate ID packet for that employee number. This is thenconverted to the format of database 3324 and processed by system 3320.

Referring now to FIG. 34, there is illustrated a diagrammatic view of anexample of a transaction. In this transaction, it is desirable to haveinformation about employees as to the number of days they worked and thenumber of days they did not work. This information is analyzed in themaster data system 3202. Therefore, the first thing that must beperformed is a conversion from the employee number to a data packet, thedays in information to a data packet and the days out information to adata packet. The employee number has previously been determined througha profiling operation to be defined as a unique ID packet. Therefore, arelational database can be utilized to pull the employee number from adatabase that is associated with the conversion block. The days ininformation can also be a unique data packet. For example, there couldbe a unique data packet for the days in information for values from1-364, each different. Alternatively, there can be a single ID packetassociated with the days in field and then a collateral or ancillaryvalue data field that could be transmitted after the ID packet, asdescribed hereinabove with respect to variable length data. This is thesame situation with the days out field.

The information is illustrated in a table 3402 in the native database.This is converted to a packetized value for a given row in a transactionpacket. The first ID packet, IDPKT P, 3404 is generated to indicate theprocess that is being carried out, i.e., employee information regardingthe days in and days out as being transferred to the master data system3202 for the purpose of evaluating information in a particular process.This is followed by an ID packet 3406 labeled “IDPKT EM” for theemployee number. Followed by that would be an ID packet 3408 for thedays in. This is followed by an ID packet 3412 for the days outinformation. At the end of the information is provided a terminationdata packet 3418. This represents a single row of information beingtransferred, although it should be understood that the initiation of theprocess could constitute multiple rows and information in the form of anID packet could be forwarded as a part of the transaction packetindicating the block size of the data that would be sent. This is then“stacked” in a stack 3420 such that it is stacked in a processing stringas opposed to an organized data structure of columns and rows. Since thedata is comprised of data packets, it is possible to place the data insuch an organization.

Referring now to FIG. 34A, there is illustrated a diagrammatic view ofhow the database is populated with ID packets. It can be seen that thereare two columns, one for employee and one for an ID packet thatrepresents data in and data out. It can be seen that unlike data isstored in the second column, i.e., that the information regarding daysin is different than that regarding days out in that it would normallybe contained within different columns of a database. This facilitatesthe processing operation. Therefore, by utilizing ID packets, the IDpackets can be assembled in single columns representing different data.Further, they can be assembled in the column in the sequence in whichinformation is to be processed in the later analysis routine.

Although the preferred embodiment has been described in detail, itshould be understood that various changes, substitutions and alterationscan be made therein without departing from the spirit and scope of theinvention as defined by the appended claims.

1. A method for communicating between first and second unlike systems,comprising the steps of: generating information at the first system in afirst information format that is native to the first system; convertingwith a first conversion system in a first conversion operation thegenerated information to a master space format such that a firstconverted information transmission is generated; transmitting the firstconverted information to a master information system; in response toreceiving the first converted information at the master informationsystem, routing the received first converted information to a secondconversion system in the master system format; at the second conversionsystem, converting the information transmitted thereto from the masterspace format to a second information format in a second conversionoperation to provide a second converted information transmission, thesecond information format being native to the second system; and routingthe second converted information transmission to the second system. 2.The method of claim 1, wherein the master space format comprises auniversal format through which all information is processed between thefirst and second systems such that unlike information in unlike formatsbetween the first and second system can be made compatible with theother of the first and second systems.
 3. The method of claim 1, whereinthe generated information comprises data at the first system and thefirst information format comprises a first data format and the masterspace format comprises a master data format and the second informationformat comprises a second data format.
 4. The method of claim 3, whereinthe master data format comprises a finite length data packet, the finitelength data packet having a unique value that has a relationship betweenthe unique value and information in a relational database, which firstand second conversion operations are associated with the relationaldatabase, such that conversion from the first data format to the masterdata format utilizes the information in the relational database andconversion of the information in the master data format to the seconddata format utilizes information in the relational database.
 5. Themethod of claim 1, and further comprising the step of modifying theinformation received from the first system at the master informationsystem prior to converting it to the second converted information formatfor transmission to the second system in the second conversion system inaccordance with a predetermined modification algorithm.
 6. The method ofclaim 4, wherein each of the finite length data packets have associatedtherewith in the unique value a classification system, such that theunique value classifies the information contained therein in apredetermined hierarchal structure.
 7. The method of claim 6, whereineach of the unique finite length data packets is divided into aplurality of portions, at least one portion associated with an entitythat is permanently associated with the data packet.
 8. The method ofclaim 7, wherein at least another portion of the finite length datapacket is associated with an entity or system that created the overalldata packet.
 9. The method of claim 7, wherein one portion of the finitelength data packet is associated with an item or an object that isuniquely defined by the finite length data packet.
 10. The method ofclaim 7, wherein each portion of the finite length data packet isassociated with information that is contained within the relationaldatabase and associated therewith.
 11. The method of claim 4, whereinthe finite length data packet has a universal format associated with themaster information system as the master data format such that each ofthe first and second data conversion system can determine therelationship between each of the finite length data packets andinformation stored in a relational database.
 12. The method of claim 4,wherein the generated information at the first system in the first dataformat comprises a plurality of the finite length data packets arrangedas a transaction packet.
 13. The method of claim 12, wherein at leastone of the finite length data packets comprises a value that isassociated with a process that is utilized in the conversion operationin either the first or second conversion system.
 14. The method of claim12, wherein at least one of the finite length data packets in thetransaction packet is associated with a data value in the relationaldatabase.
 15. A method for communicating with first and second unlikesystems to an unlike master information system for processing ofinformation therein, comprising the steps of: generating firstinformation at the first system in a first information format that isnative to the first system; generating second information at the secondsystem in a second information format that is native to the secondsystem; converting with a first conversion system in a first conversionoperation the first generated information to a master space format suchthat a first converted information transmission is generated;transmitting the first converted information to the master informationsystem; converting with a second conversion system in a secondconversion operation the generated information to the master spaceformat such that a second converted information transmission isgenerated; transmitting the second converted information to the masterinformation system; and in response to receiving the first and secondconverted information at the master information system, processing thereceived first and second converted information in the master systemformat in accordance with a predetermined processing algorithm toprovide a result.
 16. The method of claim 15, wherein the master spaceformat comprises a universal format through which all information isprocessed from the first and second systems such that unlike informationin unlike formats from the first and second systems can be madecompatible with the other of the master space format.
 17. The method ofclaim 15, wherein the first generated information comprises data at thefirst system and the first information format comprises a first dataformat the second generated information comprises data at the secondsystem and the second information format comprises a second data formatand the master space format comprises a master data
 18. The method ofclaim 17, wherein the master data format comprises a finite length datapacket, the finite length data packet having a unique value that has arelationship between the unique value and information in a relationaldatabase, which first and second conversion operations are associatedwith the relational database, such that conversion from the first dataformat to the master data format utilizes the information in therelational database and conversion from the second data format to themaster data format utilizes the information in the relational database.19. The method of claim 18, wherein each of the finite length datapackets have associated therewith in the unique value a classificationsystem, such that the unique value classifies the information containedtherein in a predetermined hierarchal structure.
 20. The method of claim19, wherein each of the unique finite length data packets is dividedinto a plurality of portions, at least one portion associated with anentity that is permanently associated with the data packet.
 21. Themethod of claim 20, wherein at least another portion of the finitelength data packet is associated with an entity or system that createdthe overall data packet.
 22. The method of claim 20, wherein one portionof the finite length data packet is associated with an item or an objectthat is uniquely defined by the finite length data packet.
 23. Themethod of claim 20, wherein each portion of the finite length datapacket is associated with information that is contained within therelational database and associated therewith.
 24. The method of claim18, wherein the finite length data packet has a universal formatassociated with the master information system as the master data formatsuch that each of the first and second data conversion systems candetermine the relationship between each of the finite length datapackets and information stored in a relational database.
 25. The methodof claim 18, wherein the first and second generated information at therespective one of the first and second systems in the respective firstor second data format comprises a plurality of the finite length datapackets arranged as a transaction packet.
 26. The method of claim 25,wherein at least one of the finite length data packets comprises a valuethat is associated with a process that is utilized in the conversionoperation in either the first or second conversion systems.
 27. Themethod of claim 25, wherein at least one of the finite length datapackets in the transaction packet is associated with a data value in therelational database.